We could also do something like the stepfunctions API and have a fluent factory class to reduce the verbosity.

public final class DynamoDbFluent {

   public static AttributeValue.Builder attributeValue();

   public static PutItemRequest.Builder putItemRequest();

}

I think they're both useful in different situations. The UnaryOperation one is when we can unambiguously determine the type, the SdkBuilder one is when we cannot (ie there's multiple implementations).

I also like the named static methods that will create a builder for you - that was actually in my original builder proposal way back when

I've got to be honest:

DynamoDBAsyncClient.builder().asyncHttpConfiguration(
    b -> b.httpClientFactory(NettySdkHttpClientFactory.builder()
                                                      .maxConnectionsPerEndpoint(MAX_CONNECTIONS)))
                           .build();

This example is really hard to read. I can't really tell what it's doing the same way as the first.

I'm worried we're going overboard with these methods.

Also, I'm a bit confused why we don't have to call build() on the NettySdkHttpClientFactory.Builder? Didn't our usability studies say that people want to call .build()?

Definitely open to other suggestions here - this pattern makes sense to me, the IDE helps you a lot - I think there's similar patterns in languages like Kotlin/Scala so hopefully it's a pattern that's becoming more prevalent. We already use this pattern on our model object's copy method. However if there's confusion about how to use it among our team, then there's likely to be confusion more widely. As I see it we can solve this in one of two ways:

1. A better pattern (as I say, open to suggestions here - this was the best I could come up with)
2. Better documentation / examples

Also, I'm a bit confused why we don't have to call build() on the NettySdkHttpClientFactory.Builder? Didn't our usability studies say that people want to call .build()?

I didn't remember this specific piece of feedback. I suppose it's down to personal preference? In any case I don't think we'd take away the other methods, this just gives customers the option of omitting the build() call if they so choose.

Sorry to be that guy, but we need to talk about applying that (excluding build()) consistently across the SDK if we're going to add it here.

Based on the feedback offline have removed the overload that takes a builder and calls build on behalf of the caller.